ETSI TS 101 493-2 vi.i.i (2000-04) 

Technical Specification 



Broadband Radio Access Networks (BRAN); 

HIPERLAN Type 2; 

Packet based Convergence Layer; 

Part 2: Ethernet Service Specific Convergence 

Sublayer (SSCS) 




ETSI TS 101 493-2 V1.1.1 (2000-04) 



Reference 



DTS/BRAN-0024004-2 
Keywords 



HIPERLAN, broadband, access, radio 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Siret N°348 623 562 00017 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network 

drive within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/ 

If you find errors in the present document, send your comment to: 
editor@etsi.fr 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2000. 
All rights reserved. 



ETSI 



ETSI TS 101 493-2 V1.1.1 (2000-04) 



Contents 



Intellectual Property Rights 5 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions, symbols and abbreviations 7 

3.1 Definitions 7 

3.2 Symbols 7 

3.3 Abbreviations 7 

4 Overview 8 

5 User Plane 9 

5.1 General 9 

5.2 Primitives (informative) 10 

5.2.1 Primitive types 10 

5.2.2 Parameter definitions 10 

5.2.3 Interface to the Ethernet Layer 11 

5.2.4 Interface to the Common Part 11 

5.3 Functionality 11 

5.3.1 General 11 

5.3.2 Coding of the Ethernet SSCSPDU 12 

5.4 Procedures 13 

5.4.1 General 13 

5.4.2 Procedures at the sender - Access Point 13 

5.4.3 Procedures at the sender - Mobile Terminal 15 

5.4.4 Procedures at the receiver - Access Point 16 

5.4.5 Procedures at the receiver - Mobile Terminal 17 

6 Control Plane 17 

6.1 General 17 

6.2 Convergence Layer specific parameters 18 

6.2.1 Convergence Layer Identifier 18 

6.2.2 Convergence Layer Version 18 

6.2.3 Maximum Transmission Unit 18 

6.3 Information Elements for Ethernet SSCS 18 

6.3.1 Information element format 18 

6.3.2 Information element type coding 19 

6.3.3 IEEE 802 MAC Address IE 19 

6.3.4 AP Network Address IE 19 

6.4 Procedures 21 

6.4.1 Association 21 

6.4.2 Network Handover 22 

6.4.3 Multicast 22 

6.4.4 Miscellaneous 22 

7 Ethernet SSCS MIB 23 

Annex A (normative): Numbering and Coding Conventions 24 

Annex B (informative): Association procedure for Ethernet SSCS 25 

Annex C (informative): Example of the MAC_ID table 29 

Bibliography 30 

History 31 



ETSI 



4 ETSI TS 1 01 493-2 V1.1.1 (2000-04) 

7 Ethernet SSCS MIB 23 

Annex A (normative): Numbering and Coding Conventions 24 

Annex B (informative): Association procedure for Ethernet SSCS 25 

Annex C (informative) : Example of the MAC_ID table 29 

Bibliography 30 

History 31 



ETSI 



ETSI TS 101 493-2 V1.1.1 (2000-04) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

It defines the functionality required for interworking High PErformance Radio Local Area Network Type 2 
(HIPERLAN/2) with IEEE 802.3 Local Area Networks [5], Separate ETSI documents provide details on the system 
overview, data link control layer, radio link control sublayer, other convergence sublayers and conformance testing 
requirements for HIPERLAN/2. 

The Packet based Convergence Layer is split into two parts, a Common Part and a Service Specific Part. The Common 
Part describes the functionality for adapting variable length packets/frames to the fixed size data units used at the Data 
Link Control (DLC) layer while the Service Specific part describes the functionality required to support a certain 
protocol, e.g. Ethernet or IP. It is envisioned that several, independent, Service Specific Convergence Sublayers (SSCS) 
will be defined in the future as market requirements develop. The SSCSs all use the services of the Common Part and 
the DLC. 

The present document is part 2 of a multi-part TS covering the Packet based Convergence Layer, as identified below: 

Parti: "Common Part"; 

Part 2: "Ethernet Service Specific Convergence Sublayer". 

Further SSCSs will be added in the future. 
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Scope 



The present document is applicable to HIPERLAN/2 equipment supporting interworking with IEEE 802.3 Local Area 
Networks [5]. 

The present document does only address the functionality required to transfer IEEE 802.3 [5] frames over the radio 
interface between an HIPERLAN/2 Access Point and Mobile Terminal. Note that the frame type described in 
IEEE 802.3 also covers Ethernet v2 (see Bibliography). It does not address the requirements and technical 
characteristics for wired network interfaces at the Access Point and at the Mobile Terminal. 

The present document supports both best effort and the IEEE 802. lp priority mechanisms developed to enable 
Quality-of-Service in LANs. 

The present document uses the services provided by the Common Part of the Packet based Convergence Layer and by 
the Data Link Control layer of HIPERLAN/2. 

The present document does not address the requirements and technical characteristics for type approval and 
conformance testing. These are covered in separate Technical Specifications. 
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3.1 



Definitions, symbols and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

HIPERLAN/2: High PErformance Radio Local Area Network Type 2, a short-range wireless LAN providing 
broadband local access. Standardized by ETSI Project BRAN 

Maximum Transmission Unit (MTU): maximum packet size in octets that can be conveyed in one piece over a link 

Protocol Data Unit (PDU): data unit exchanged between entities at the same ISO layer 

Service Data Unit (SDU): data unit exchanged between adjacent ISO layers 



3.2 Symbols 

For the purposes of the present document, the following symbol applies: 



Ox 



Hexadecimal notation 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AP Access Point 

BRAN Broadband Radio Access Networks (Project) 

CL Convergence Layer 

CPCS Common Part Convergence Sublayer 

C-SAP Control Service Access Point 

DLC Data Link Control 

DLCC DLC Connection 

DUC DLC User Connection 

ETSI European Telecommunications Standards Institute 

HIPERLAN/2 High Performance Radio Local Area Network Type 2 

H/2 see HIPERLAN/2 

HO Handover 

IE Information Element 

IEEE Institute of Electrical and Electronics Engineers 

IP Internet Protocol 

IPv4 IP version 4 

IPv6 IP version 6 

LAN Local Area Network 

LLC Logical Link Control 

LSB Least Significant Bit 

M-SAP MAC Service Access Point 

MAC Medium Access Control 

MSB Most Significant Bit 

MT Mobile Terminal 

MTU Maximum Transmission Unit 

PDU Protocol Data Unit 

QoS Quality of Service 

RLC Radio Link Control 

RFC Request For Comments 

SAP Service Access Point 
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SDU 

SFD 

SNMP 

SSCS 

TCI 

TCP 

TPID 

UDP 



Service Data Unit 

Start Frame Delimiter 

Simple Network Management Protocol 

Service Specific Convergence Sublayer 

Tag Control Information field 

Transmission Control Protocol 

Tag Protocol Identifier 

User Datagram Protocol 



Overview 



The Ethernet Service Specific Convergence Sublayer is a part of the Packet based Convergence Layer and it resides on 
top of the Common Part and the DLC. It provides a method of using and preserving the IEEE 802.3 frame format over 
the radio interface by adapting service requests for transmission and reception of 802.3 frames to bearer services offered 
by the DLC. 

All Mobile Terminals (MT), associated to the same AP, appear like connected to one common fixed shared medium 
LAN segment. In contrast to a normal fixed LAN segment where all terminals are able to listen to all traffic on the 
segment, traffic that is originated by one MT is always first sent up to the AP. It is then the task of the AP to relay the 
traffic to either the fixed network and/or to other MTs associated to that AP. 

The network topology when applied to HIPERLAN/2 is shown in figure 4. 1 . Please note that the scope of the Ethernet 
SSCS is limited to the radio interface only (shaded in grey). The architecture of the AP, e.g. if it only contains Layer 2 
(i.e. MAC bridging) functionality or if it also includes Layer 3 (i.e. IP routing) functionality, is not standardized. 
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Figure 4.1 : HIPERLAN/2 network topology using Ethernet SSCS 

The corresponding protocol model for Ethernet SSCS is depicted in figure 4.2. The Ethernet SSCS replaces the MAC 
entity in the IEEE 802 model. At the MT, the CL User Service Access Point is mapped to the M-SAP, the SAP between 
IEEE 802.2 (LLC) and the IEEE 802.3 (MAC) layers. At the AP, the Ethernet SSCS replaces the IEEE 802.3 MAC 
entity and interacts with the MAC relay entity of an IEEE 802. ID bridge. 
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Application 



E.g. TCP/UDP 



E.g. IP 



Ethernet V2 or 
IEEE 802.3/ 802.2 framing 



Packet based CL - 
Ethernet SSCS 

Packet based CL - Common Part 



HIPERLAN/2 DLC 



HIPERLAN/2 PHY 



Scope of BRAN specifications 



Packet based CL>-~^^ IEEE 802.1 D ^^^ 
Ethernet SSCS ^^(including IEEE 802. 1p)^^ 


Packet based CL - Common Part^\^5-^^^'^ 


HIPERLAN/2 DLC 


Network specific 

protocols, 

out of scope 


HIPERLAN/2 PHY 



HIPERLAN/2 Mobile Terminal 



HIPERLAN/2 Access Point 



Figure 4.2: Ethernet SSCS architecture applied to HIPERLAN/2 

The Ethernet SSCS supports two Quality-of-Service types: 

a) Best Effort 

This is the default QoS type that shall be supported. All traffic is treated equally and no Quality-of-Service guarantees 
can be provided. 

b) IEEE 802.1p priority based QoS scheme 

IEEE 802. lp provides priority mechanisms to enable Quality-of-Service in Local Area Networks. These mechanisms 
have been incorporated into IEEE 802. ID [4]. Eight (numbered 0-7) different priority levels are defined. The user 
priorities are mapped one-to-one or many-to-one to queues, depending on the number of queues supported. In 
HIPERLAN/2 each queue corresponds to one DLC user connection. The mapping between user priorities and DLC user 
connections is defined in subclause 5.4.2. The user priority information is carried in each IEEE 802.3 frame using a Tag 
Header inserted following the source and destination address. The Tag Header is defined in [6] (see subclause 5.3.2 for 
more details on supported frame types). The support for IEEE 802. lp is optional for both the MT and AP. 

The Quality-of-Service type and additional parameters used by the SSCS are negotiated at association time using the 
control plane procedures defined in clause 6. 

The Ethernet SSCS consists of a user plane and a control plane. The user plane, described in clause 5, provides services 
to the Higher Layer via the CL-Service Access Point (SAP) and uses the services of the Common Part of the Packet 
based Convergence Layer [1]. The control plane of the Ethernet SSCS, described in clause 6, interacts with the DLC 
control plane, i.e. the RLC sublayer, via the DLC Control SAP. The DLC Control SAP is defined in [2]. 



User Plane 



5.1 



General 



The user plane procedures of the Ethernet SSCS provide the capability to transfer Ethernet SSCS SDUs between the 
Ethernet SSCS of the AP and one or more Ethernet SSCSs of MTs over the HIPERLAN/2 network. 

It is the task of the Ethernet SSCS to map the address and priority scheme of the Higher Layer to the address and 
priority scheme of the DLC layer. 

Ethernet SSCS SDUs coming from the Higher Layer are mapped onto different DLC user connections, depending on the 
Ethernet destination address and priority. The relation between Ethernet address/priority and DLC user connections is 
managed by the Ethernet SSCS control plane (see clause 6). 
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The behaviour of the user plane procedures for AP and MT is asymmetric. All MTs transfer all Ethernet SSCS SDUs to 
the Ethernet SSCS of the AP. It is the task of the Ethernet SSCS of the AP to reflect Ethernet SSCS SDUs back to the 
HIPERLAN/2 network, if necessary to emulate the behaviour of a shared medium LAN segment (see subclause 5.3). 
The AP directs the Ethernet SDUs to one Ethernet SSCS in case of unicast. In case of multicast and broadcast the AP 
directs the Ethernet SDU to one or more Ethernet SSCS of MTs, if multiple MTs have subscribed to a multicast group 
or if multiple MTs have associated to the AP. 

5.2 Primitives (informative) 

The Ethernet SSCS exchanges service primitives with the Higher Layer and the CPCS. 

NOTE: The primitives are defined only for the purpose of describing layer-to-layer and sublayer-to-sublayer 

interactions. These primitives are defined as an abstract list of parameters, and their concrete realization 
may vary between implementations. No formal testing of primitives is intended. The following primitive 
definitions have no normative significance. 

5.2.1 Primitive types 

Interface between layers 

Four primitive types may be used between different layers: 

- req (request), for a higher layer to request service from a lower layer; 

cnf (confirm), for the layer providing the service to confirm the activity has been completed; 

ind (indication), for a layer providing service to notify the next higher layer of any specific service related 
activity; 

- rsp (response), for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

Interface between sublayers 

Two different primitives may be used between different sublayers. To indicate the absence of a Service Access Point 
these primitives differ to the primitives between different layers. 

inv (invoke), for a higher layer to request service from a lower layer; 

sig (signal), for a layer providing service to notify the next higher layer of any specific service related activity. 

The defined types for each category of primitive are shown as a list in curly brackets. 

EXAMPLE: CL_UNITDATA {req, ind} 

In this example, the defined types are request and indication but not confirm or response. 

5.2.2 Parameter definitions 

Endpoint identifiers: some primitives contain an endpoint identifier. This identifier shall be used to distinguish 
primitives related to different protocol instances. As identifier the DLC User Connection ID, which is the concatenation 
of a MAC_ID and DLCC_ID [3], shall be used. The coding of this identifier is a local matter not defined in the present 
document. The identifier is defined as: 

- DLC User Connection ID (DUC_ID) 

Message unit: each piece of higher layer information that is included in the primitive is called a message unit. A series 
of one or more message units may be associated with each primitive where each separate unit is related to one 
information element in the corresponding DLC layer message. The list of message units is derived from the message 
definitions by reference to the information elements that may contain information from or (to) the CL. 
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The following primitives are used 
CLJJNITDATA {req, ind} 
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PARAMETER 


REQ 


CNF 


IND 


RSP 


Message units (possible elements) 










Destination address 


A 


- 


A 


- 


Source address 


A 


- 


A 


- 


Interface Data (SSCS-SDU) 


A 


- 


A 


- 


Priority 


O 


- 


- 


- 


NOTE: A = Always present; 






O = Optional; 






"-" = Not applicable. 







Destination address 

This parameter specifies a 48-bit IEEE MAC Destination Address as defined in [5]. 

Source address 

This parameter specifies a 48-bit IEEE MAC Source Address as defined in [5]. 

Interface Data 

This parameter specifies the Interface Data exchanged between the Higher Layer and the Ethernet SSCS entity. The 
Interface Data represents a complete Ethernet SSCS-SDU. The types of SDUs that shall be supported are described in 

subclause 5.3.2. 

Priority 

This parameter specifies the priority assigned to each Ethernet SSCS-SDU according to IEEE 802. ID [4]. 

5.2.4 Interface to the Common Part 

The interface to the Common Part of the Packet based Convergence Layer is defined in [1]. 

5.3 Functionality 
5.3.1 General 

The Ethernet Service Specific Convergence Sublayer functions are performed on an Ethernet SSCS-PDU basis. The 
Ethernet SSCS accepts different types of frames. The types that shall be supported are described in subclause 5.3.2. 

The functions implemented by the Ethernet SSCS user plane include: 

a) Preservation of Ethernet SSCS-SDU 

This function provides the delineation and transparent transfer of Ethernet SSCS-SDUs. 

b) Traffic class mapping according to 802.1p (optional) 

This function provides the mapping of different traffic classes to different priority queues, depending on how many 
priority queues are supported. 

c) Mapping of Ethernet broadcast to HIPERLAN/2 DLC broadcast service 

This function provides the mapping of Ethernet broadcast to the broadcast service offered by the HIPERLAN/2 
DLC. 
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d) Mapping of Ethernet multicast to HIPERLAN/2 DLC multicast service 

This function provides the mapping of Ethernet multicast to the multicast service offered by the HIPERLAN/2 DLC. 

e) Emulation of a collision domain 

This function provides that MTs associated to the same AP appear to be connected as if connected to a shared 
medium LAN segment. 

To emulate the behaviour of a shared medium LAN segment the following functionality is required: 

At the Access Point 

Ethernet frames shall be reflected back to the radio interface in case of: 

Ethernet broadcast frames if an MT associated to the AP is the source; 

Ethernet multicast, if multiple MTs associated to the same AP have registered to the same multicast group and 
one MT associated to the AP is the source; 

Ethernet unicast, if an MT sends frames destined to another MT that is associated to the same AP. 

In case of multicast and broadcast, the Ethernet frames shall also be forwarded to the Higher Layer. 

At the Mobile Terminal 

Ethernet traffic that has been reflected back to the radio interface shall be filtered out and discarded by the 
originating MT; 

The Higher layer shall not receive Ethernet frames that have been sent by itself before. 



5.3.2 Coding of the Ethernet SSCS PDU 



The Ethernet SSCS shall accept the Ethernet frame types described in figures 5.1 and 5.2. The Ethernet frames shall be 
mapped to the CPCS-SDU beginning with the Destination Address field and ending with the Payload (including Padding 
if present). Preamble, Start Frame Delimiter (SFD) and Frame Check Sequence (FCS) shall be omitted. 

In contrast to the transmission order specified for Ethernet [5], where the least significant bit is transmitted first on the 
physical medium, the Ethernet SSCS-PDUs shall be transmitted according to the transmission order defined in the DLC 
[3] and RLC [2], see also annex A. 



Preamble 


SFD 


Destination 
Address 


Source 
Address 


Type/ 
Length 


Variable Length payload \ PAD 


FCS 



46-1500 



SSCS SDU / SSCS PDU / CPCS SDU 



60-1514 octets 

Figure 5.1 : IEEE 802.3 frame 
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Tag Header 
•* ► 



Preamble 


SFD 


Destination 
Address 


Source 
Address 


TPI 


TCI 


Type/ 
Length 


Variable Length payload j PAD 


FCS 


7 1 


6 6 2 2 2 42-1500 


4 




SSCS SDU / SSCS PDU / CPCS SDU 





60-1518 octets 



Figure 5.2: IEEE 802.3 frame with IEEE 802. 3ac Tagging 



5.4 



Procedures 



5.4.1 



General 



The procedures of the Ethernet SSCS, defined in the following subclauses, are asymmetric and thus differ between 
Access Point and Mobile Terminal. 

5.4.2 Procedures at the sender - Access Point 

NOTE: The following parameters have no normative significance. The parameters are only defined for the 
purpose of describing the procedures of sender and receiver. 

The sender maintains the following parameters: 

<MAC ID tablo 

This table is shared by sender and receiver within one CL entity. Entries are set by control functions and entries are read 
by the sender and the receiver. The table maps IEEE 802 MAC Addresses to DLC MAC_IDs, see annex C. It is possible 
that multiple MAC_IDs are associated to one IEEE 802 MAC address in case Ethernet multicast is sent as DLC unicast. 

<Number of DLC Connections tablo 

Entries in this table, reflecting the negotiated number of DLC connections for each MAC_ID, are set by control 
functions during association and read by the sender. The number of DLC Connections shall be set to a value from 1 to 8. 

<DUC_ID> 

The DUC_ID identifies the instance of the Common Part to which the CPCS_UNITDATA invoke primitive is sent. The 
DUC_ID is the concatenation of MAC_ID and DLCCJD. 

The AP sender shall perform the following procedures: 

1) Upon reception of a CL_UNITDATA request primitive the sender validates if one or more MAC_IDs are 
registered for the <Destination address> by querying the <MAC ID tablex 

If there is no MAC_ID registered for this <Destination Address>, the SSCS-SDU shall be discarded and the 
sender waits for the next CL_UNITDATA request. 

If there are one or more MAC_IDs registered for the <Destination address>, the sender shall duplicate the 
Ethernet SSCS-SDU for each MAC_ID that is registered and shall proceed with the steps listed below for each 
Ethernet SSCS SDU: 

2) The sender shall set the DLCCJD: 

If the <Destination address> in the Ethernet SSCS-SDU is the 48-bit IEEE broadcast address as specified in [5], 
the DLCCJD shall be set to 63. 



ETSI 



14 



ETSI TS 101 493-2 V1.1.1 (2000-04) 



If the <Destination address> in the Ethernet SSCS-SDU is any of the 48-bit IEEE multicast addresses as 
specified in [5], the DLCC_ID shall be set to 63 if the related MAC_ID is one of the multicast MACJDs (224 - 
255). If the related MAC_ID is not a multicast MAC_ID, the DLCC_ID shall be set according to tables 5.1 and 
5.2, depending on the entries of the <N umber of DLC Connections table> and the <Priority> received in the 
primitive. 

If the Ethernet SSCS-SDU is an Ethernet unicast, the DLCC_ID shall be set according to tables 5.1 and 5.2, 
depending on the entries of the <Number of DLC Connections table> and the <Priority> received in the 
primitive. 

3) The sender shall construct the SSCS-PDU as shown in subclause 5.3.2. It then sends the CPCS_UNITDATA 
invoke primitive to the CPCS instance identified by the <DUC_ID>. 

IEEE 802. lp defines 8 priorities and describes which type of traffic is expected to be carried in this priority. Priority 
number 2 is currently reserved for future use. The mapping between user priority, traffic type, traffic class and 
DLCC_ID is described in tables 5.1 and 5.2. Different traffic classes are mapped to different DLCCs. After connection 
setup the RLC indicates which DLCC_IDs have been assigned to DLCCs in a list (see subclause 6.4) and traffic classes 
are mapped to DLCC_IDs depending on the numerical order of the value of the DLCC_IDs, as shown in table 5.2. 

Table 5.1 : IEEE 802.1 p Traffic Types [4] 



User priority 


Traffic Type 


Comments 


1 


Background (BK) 




2 


- 


Spare 


(Default) 


Best Effort (BE) 


Default LAN traffic 


3 


Excellent Effort (EE) 


For valued customers 


4 


Controlled Load (CL) 


Traffic will have to conform to some 
form of Higher Layer admission control 


5 


"Video" (VI) 


< 1 00 ms delay and jitter 


6 


"Voice" (VO) 


< 10 ms delay and jitter 


7 


Network Control (NC) 
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Table 5.2: Mapping between IEEE 802.1 p and DLCC-ID 



Number of 
DLCCs 


Traffic Classes 


DLCC-ld 


1 


{ Best Effort, Excellent Effort, Background, Voice, Controlled 
Load, Video, Network Control } 


Lowest 


2 


{ Best Effort, Excellent Effort, Background } 

{ Voice, Controlled Load, Video, Network Control } 


Lowest 
2 nd lowest 


3 


{ Best Effort, Excellent Effort, Background } 
{ Controlled Load, Video } 
{ Voice, Network Control } 


Lowest 
3 rd lowest 
2 nd lowest 


4 


{ Background } 

{ Best Effort, Excellent Effort } 
{ Controlled Load, Video } 
{ Voice, Network Control } 


4 tn lowest 
Lowest 
3 rd lowest 
2 nd lowest 


5 


{ Background } 

{ Best Effort, Excellent Effort } 

{ Controlled Load } 

{ Video } 

{ Voice, Network Control } 


4 tn lowest 
Lowest 
3 rd lowest 
5 th lowest 
2 nd lowest 


6 


{ Background } 

{ Best Effort } 

{ Excellent Effort } 

{ Controlled Load } 

{ Video } 

{ Voice, Network Control } 


4 tn lowest 
Lowest 
6 th lowest 
3 rd lowest 
5 th lowest 
2 nd lowest 


7 


{ Background } 

{ Best Effort } 

{ Excellent Effort } 

{ Controlled Load } 

{ Video } 

{ Voice} 

{ Network Control } 


4 tn lowest 
Lowest 
6 th lowest 
3 rd lowest 
5 th lowest 
2 nd lowest 
7 th lowest 


8 


{ Background } 
{ Best Effort } 
{ Excellent Effort } 
{ Controlled Load } 
{ Video } 
{ Voice} 

{ Network Control } 
{ Spare } 


4 tn lowest 
Lowest 
6 th lowest 
3 rd lowest 
5 th lowest 
2 nd lowest 
7 th lowest 
8 th lowest 



NOTE: The traffic types written in bold are the distinguishing traffic types that have driven the allocation of types 
to classes. The "Spare" queue is reserved for future use. The traffic type for this queue has not been 
specified in 802. lp. 

EXAMPLE: The RLC indicates that the following DLCCJDs have been assigned to DLCCs: [DLCC_ID=6, 
DLCC_ID=4]. The traffic class {Best effort, Excellent Effort, etc.} shall be mapped to 
DLCC_ID= 4, as this is the lowest DLCC_ID number, while the traffic class {Voice, Controlled 
Load etc.} shall be mapped to DLCC_ID=6. 

5.4.3 Procedures at the sender - Mobile Terminal 

NOTE: The following parameters have no normative significance. The parameters are only defined for the 
purpose of describing the procedures of sender and receiver. 

The sender maintains the following parameters: 

<Number of DLC Connections> 

This parameter is set by control functions during association and read by the sender. It reflects the negotiated number of 
DLC connections. It shall be set to a value from 1 to 8. 
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<DUC_ID> 



The DUC_ID identifies the instance of the Common Part to which the CPCS_UNITDATA invoke primitive is sent. The 
DUC_ID is the concatenation of MAC_ID and DLCC_ID. 

The MT sender shall perform the following procedures: 

1) The sender shall set the DLCC_ID according to tables 5.1 and 5.2, depending on the <Number of DLC 
Connections> and the <Priority> received as parameter. 

2) The sender shall construct the SSCS PDU as shown in subclause 5.3.2. Then it sends the CPCSJJNITDATA 
invoke primitive to the CPCS instance identified by the <DUC_ID>. 

NOTE: Ethernet broadcast and multicast originated by the MT is sent as unicast traffic to the AP. The AP 
distributes this traffic if applicable. 

5.4.4 Procedures at the receiver - Access Point 

NOTE: The following parameters have no normative significance. The parameters are only defined for the 
purpose of describing the procedures of sender and receiver. 

The receiver maintains the following parameters: 

<MAC ID tablo 

This table is shared by sender and receiver within one CL entity. Entries are set by control functions and entries are read 
by the sender and the receiver. The table maps IEEE 802 MAC Addresses to DLC MAC_IDs. It is possible that multiple 
MAC_IDs are associated to one IEEE 802 MAC address in case of multicast, see also annex C. 

<DUC_ID> 

The DUC Identifier identifies the instance of the Common Part to which the CPCS_UNITDATA invoke primitive is 
sent. The DUC_ID is the concatenation of MAC_ID and DLCC_ID. 

The AP receiver shall perform the following procedures: 

1) When the receiver receives a CPCS_UNITDATA signal primitive the receiver examines the value of the 
destination address, which is always sent in the first 6 octets of the Interface Data. 

2) If the destination address is equal to the 48-bit IEEE 802 MAC broadcast address, the receiver shall invoke the 
the sender procedure at the same entity with the Interface Data. The sender shall treat the SDU as if it was 
received in a CL_UNITDATA request. The receiver shall create a CL_UNITDATA indication primitive 
including the parameters, Source Address, Destination Address and Interface Data and send it also to the Higher 
Layer. 

3) If the destination address is equal to any 48-bit IEEE 802 MAC multicast address and more than one MAC_IDs 
are registered to this address, the receiver shall invoke the sender procedure at the same entity with the Interface 
Data. The sender shall treat the SDU as if it was received in a CL_UNITDATA request. The receiver shall create 
a CL_UNITDATA indication primitive including the parameter Source Address, Destination Address and 
Interface Data and send it also to the Higher Layer. 

4) If the destination address is equal to any 48-bit IEEE 802 MAC unicast address and a MAC_ID is registered for 
this address, the receiver shall invoke the sender procedure at the same entity with the Interface Data. The sender 
shall treat the SDU as if it was received in a CL_UNITDATA request. 

5) In all other cases the receiver shall create a CL_UNITDATA indication primitive including the parameters, 
Source Address, Destination Address and Interface Data and send it to the Higher Layer. 
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5.4.5 Procedures at the receiver - Mobile Terminal 

The receiver maintains the following parameter: 

<Own IEEE address> 

This parameter is used to filter traffic that has been sent by the MT and was subsequently received by it. The parameter 
corresponds to the 48-bit IEEE 802 MAC address of the Mobile Terminal. 

The MT receiver shall perform the following procedures: 

1) When the receiver receives a CPCS_UNITDATA signal primitive the receiver shall compare the Source 
Address, the six octets following the Destination Address of the Interface Data, to the parameter <Own IEEE 
address>. 

2) If the Source Address is equal to the value of <Own IEEE address>, the Interface Data shall be discarded. 

3) If the Source Address is not equal to the value of <Own IEEE address>, the receiver shall create a 
CL_UNITDATA indication primitive including the parameters, Source Address, Destination Address and 
Interface Data and send it to the Higher Layer. 



6 Control Plane 

6.1 General 

The control plane of the Ethernet SSCS interacts with the DLC control plane (i.e. the RLC sublayer) via the DLC 
Control Service Access Point defined in [2]. 

The following functions are performed by the control plane procedures of the Ethernet SSCS: 

a) Implicit QoS type negotiation during association and network handover (using DLC connection setup procedures); 

b) Triggering of MT originated DLC connection setup at association and network handover; 

c) Triggering of DLC multicast and broadcast join procedures; 

d) AP network address transfer during association and network handover; 

e) MT IEEE 802 MAC address transfer during association and network handover. 

The following DLC C-SAP primitives [2] are used by the control plane procedures of the Ethernet SSCS: 

- DLC_SETUP- {req, ind}; 

- DLC_CONNECT - { req, cnf, ind, rsp } ; 

- DLCJVIULTIC ASTJOIN - { req, cnf, ind, rsp } ; 

- DLC_MULTIC AST_LEAVE - { req, ind } ; 

- DLC_CL_BROADCAST_JOIN - { req, cnf, ind, rsp } ; 

- DLC_INFO_TRANSFER - { req, cnf, ind, rsp } . 
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6.2 Convergence Layer specific parameters 



6.2.1 Convergence Layer Identifier 



The Convergence Layer ID used in the RLC [2] shall be set according to the table below to indicate the support of 
Ethernet SSCS in the MT and AP. Bits 6 to 8 identify the Convergence Layer. In case of the Packet based Convergence 
Layer bits 1 to 5 identify the Service Specific Convergence Sublayer (SSCS). 



Bits 8765432 1 



Meaning 



1 Ethernet SSCS supported 
All other values are reserved for other Convergence Layers. 



6.2.2 Convergence Layer Version 



The Convergence Layer Version number is an 8-bit field used in the RLC [2], This field is split into two 4-bit subfields. 
The four most significant bits (bits 5 to 8) identify the version of the Common Part and the four least significant bits 
(bits 1 to 4) identify the version of the SSCS. The Convergence Layer Version number shall be set according to the table 
below to indicate the support of this edition (version 1) of the Ethernet SSCS. 



Bits 8765432 1 



xxxxOOO 1 



Meaning 



Ethernet SSCS version 1 supported 



6.2.3 Maximum Transmission Unit 

The Maximum Transmission Unit (MTU) used in the Common Part of the Packet based Convergence Layer [1] shall be 
set to 1518 octets. 



6.3 



Information Elements for Ethernet SSCS 



6.3.1 Information element format 

In order to transfer Convergence Layer specific information between AP and MT a number of CL information elements 
are defined. These Convergence Layer specific information elements are transferred transparently by RLC messages 
within the RLC specific information element «CL-ATTRIBUTES» [2]. Each Convergence Layer information 
element consists of a Type field, a Length field and an Information field, see figure 6.1. 

The purpose of the Information Element Type is to identify the information element being sent. The IE Type field is 8 
bits, allowing for up to 256 information elements to be defined for a certain SSCS. 

The Reserved field is for future use and shall be coded as zero. 

The Length field indicates the length of the Information field in octets. It does not include the length of the IE Type 
field, the Reserved field, or the length of the Length field itself. 

Octets 

1 

2 
3 

L + 2 
Figure 6.1 : Convergence Layer information element structure 



8 7 


6 


Bits 
5 4 3 


2 


1 


IE Type 


Reserved 


Length (L) 


Information 
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6.3.2 Information element type coding 

The following IE Type codes are used in the Ethernet SSCS: 
Bits 8 7 6 5 4 3 2 1 



00000000 
00000001 



Meaning 



IEEE 802 MAC Address (see subclause 6.3.3) 
AP Network Address (see subclause 6.3.4) 



6.3.3 



All other values are reserved for future lEs. 



IEEE 802 MAC Address IE 



The «IEEE 802 MAC Address» information element is used to inform the AP of the MT's IEEE 802 MAC address 
during association and handover. The information element is also used in the multicast and broadcast procedures to 
inform the AP about the IEEE 802 MAC address of a certain multicast or broadcast group it wants to join or leave (in 
case of multicast). 



Octets 

1 

2 
3 
4 
5 
6 
7 
8 



Figure 6.2: IEEE 802 MAC Address information element 

6.3.4 AP Network Address IE 

The purpose of the «AP Network Address» information element is to facilitate routing of network handover messages 
between APs via the fixed network. It is also used to inform the MT about a change of the network topology, e.g. change 
of IP subnet, during a handover. The AP shall provide this IE to the MT at association time and at Network Handover. 
The MT shall provide the IE to the new AP during Network Handover. The address type used in the network is out of 
scope of the present document. 



8 7 


Bits 
6 5 4 3 


2 


1 


«IEEE 802 MAC Address» 


Reserved 


Length (L) 


MSB 


IEEE 802 MAC Address 




LSB 



Address Type (octet 4) 



Bits 8765432 1 



00000000 
00000001 
00000010 
000000 1 1 



Meaning 



IEEE 802 48 bit MAC address 
IEEE EUI-64 address 
IP version 4 address 
IP version 6 address 



All other values are reserved for future use. 



AP Network Address (octet 5 . . . ) 



Address Type 


Reference 


Length (octets) 


IEEE 802 48 bit MAC address 


[5] 


6 


IEEE EUI-64 


[71 


8 


IP version 4 address 


RFC 791, [8] 


4 


IP version 6 address 


RFC 2373, [9] 


16 
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AP IPv4 Subnet Mask (32 bits) 

The AP IPv4 Subnet Mask is used to inform the MT about the subnet mask of the IP subnet to which the AP is attached. 
This field is optional and only valid together with an IP version 4 address type in the AP to MT direction. The subnet 
mask has a length of 32 bits. 



Octets 

1 

2 
3 
4 



8 7 


Bits 
6 5 4 3 


2 


1 


«AP-NETWORK-ADDRESS» 


Reserved 


Length (L) 


Address Type 


MSB 


AP Network Address 







LSB L + 2 



Figure 6.3: AP Network Address information element 



8 7 


Bits 
6 5 4 3 


2 


1 


«AP-NETWORK-ADDRESS» 


Reserved 


Length (= 5 or 9) 


Address Type = IPv4 


MSB 


AP IPv4 address 




LSB 



MSB 



AP IPv4 Subnet mask 



LSB 



Octets 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 



NOTE: AP IPv4 Subnet mask is optional and only used with an IPv4 address. 
Figure 6.4: AP Network Address information element (for IPv4 address + IPv4 Subnet mask) 

AP IPv6 Prefix Length (8 bits) 

The AP IPv6 Prefix Length is used to inform the MT about the length of the IPv6 address prefix of the AP. This field is 
optional and only valid together with an IP version 6 address type in the AP to MT direction. The Prefix Length is a 
binary coded value specifying how many of the leftmost continuous bits of the address comprise the prefix. 



Octets 

1 

2 
3 
4 

19 
20 



8 7 


Bits 
6 5 4 3 2 1 


«AP-NETWORK-ADDRESS» 


Reserved 


Length (= 17 or 18) 


Address Type = IPv6 


MSB 


AP IPv6 Network Address 



LSB 



AP IPv6 Prefix Length 
AP IPv6 Prefix Length is optional and" only used with an IPv6 address. 



NOTE: 
Figure 6.5: AP Network Address information element (for IPv6 address + IPv6 Prefix Length) 
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6.4 



Procedures 



6.4.1 Association 

The information field of the «CL-ATTRIBUTES» IE in the DLC_INFO_TRANSFER request primitive triggered by 
the MT during association, see [2], shall contain the following CL information element: 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Subclause 
6.3.3 


M 


8 


Contains the IEEE 802 MAC address of the MT 



Upon receiving a DLC_INFO_TRANSFER indication the AP shall update the <MAC ID table> with the IEEE 802 
MAC address of the MT received in the «CL-ATTRIBUTES» IE and the MAC ID assigned to the MT by the DLC. 

The AP shall then respond with a DLC_INFO_TRANSFER response primitive. The information field in the «CL- 
ATTRIBUTES» information element sent in the primitive shall contain the following CL information element: 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


AP Network Address 


Subclause 
6.3.4 


M 


7-20 


Contains the network address of the AP 



Upon receiving a DLC_INFO_TRANSFER confirm primitive the MT shall issue a DLC_CL_BROADCAST_JOIN 
request primitive containing the Ethernet broadcast address (Ox) FF:FF:FF:FF:FF:FF. This address shall be transferred 
by the IEEE 802 MAC address information element within the «CL_ATTRIBUTES» IE, see below. 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Subclause 
6.3.3 


M 


8 


Contains the IEEE 802 MAC broadcast address 
(Ox) FF:FF:FF:FF:FF:FF 



Upon reception of DLC_CL_BROADCAST_JOIN indication primitive the AP shall add the IEEE 802 MAC broadcast 
address and the broadcast MAC ID allocated by the DLC to the <MAC ID table>. 

The AP then issues a DLC_CL_BROADCAST_JOIN response primitive. The MT receives a 
DLC_CL_BROADCAST_JOIN confirm primitive including the MAC ID allocated by the AP for Ethernet broadcast. 

NOTE: A single MAC ID is allocated by the AP for all Ethernet broadcasts. 

The MT shall then trigger a connection setup by issuing a DLC_SETUP request primitive including the number of 
connections it wants to use. One DLCC equals best effort mode, while 2 to 8 DLCCs indicate that the MT wants to use 
IEEE 802. lp. 

Upon receiving a DLC_SETUP indication primitive the AP shall compare the number of connections requested by the 
MT with the number of connections supported by the AP. The AP decides on the number of DLC connections that shall 
be used. However, the value chosen shall not exceed the number of connections requested by the MT. The AP sets the 
<Number of DLC connections table> entry for the MAC ID of the MT and shall then respond with a DLC_CONNECT 
request primitive including the number of DLC connections the MT shall use. 

Upon reception of a DLC_CONNECT indication primitive the MT shall set the <Number of DLC connections> 
parameter. An indication is sent to the user plane that the MT is associated and user plane operation may commence. 

Upon reception of a DLC_CONNECT confirm primitive the SSCS in the AP shall indicate to the user plane that the MT 
has been successfully associated and user plane operation may commence 

The details of the association procedure are shown in annex B. 
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6.4.2 Network Handover 

For the CL the procedures for Network Handover are the same as the association procedure described in the previous 
subclause, with the following exceptions: 

1) The «CL-ATTRIBUTES» IE in the DLC_INFO_TRANSFER request primitive triggered by the MT during 
network handover, see [2], shall contain also the AP Network Address of the old AP, see below. 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Subclause 
6.3.3 


M 


8 


Contains the IEEE 802 MAC address of the MT 


AP Network Address 


Subclause 
6.3.4 


M 


7-19 


Contains the network address of the old AP 



The AP Network Address shall be the address of the AP to which the MT was associated before the handover. This 
information may be used by an inter- AP handover protocol specified in the future. 

2) After the connection setup the MT shall join the multicast groups, see subclause 6.4.3, which it had joined at the old 
AP. 

NOTE: If Network Handover is supported via the core network the DLC C-S AP primitives triggered by the CL 
may be ignored by the RLC. 

6.4.3 Multicast 

The «CL-ATTRIBUTES» information element in the DLC_MULTICAST_JOIN request primitive triggered by the 
MT shall contain the following information element: 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Subclause 
6.3.3 


M 


8 


Contains the IEEE 802 MAC multicast group 
address the MT wants to join. 



NOTE: The MT may request to join several multicast groups simultaneously, in which case several IEEE 802 
MAC address IEs will be included in the «CL-ATTRIBUTES» in the DLC_MULTICAST_JOIN 

primitives. 

Upon reception of a DLC_MULTICAST_JOIN indication primitive the AP updates the <MAC_ID table> with the 
IEEE 802 MAC multicast address received from the MT and the corresponding MAC ID allocated by the AP. This can 
either be a multicast MAC ID or a unicast MAC ID. Each IEEE 802 MAC multicast group address can correspond to 
several MAC IDs. 

The AP triggers a DLC_MULTICAST_JOIN response primitive. Upon reception of DLC_MULTICAST_JOIN confirm 
the MT user plane operation for this multicast address may commence. Filtering for this multicast address at the MT is 
handled in the DLC layer. 

The DLC_MULTICAST_LEAVE primitive triggered by the MT shall contain the IEEE 802 MAC address of the 
multicast group the MT wants to leave, as in the multicast join procedure (see above). Upon reception of a 
DLC_MULTICAST_LEAVE indication the AP shall remove the entry for that multicast group from the <MAC ID 
table> if the MT was the only member of the multicast group. 

6.4.4 Miscellaneous 



When the AP notices that an MT has left or upon reception of a disassociation indication the AP shall remove all entries 
in the <MAC ID Table> for that MT. If the MT was the only member of a multicast group the entry for that group shall 
be removed. 
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7 Ethernet SSCS MIB 



The Management Information Base parameters for the Ethernet SSCS of the Packet based Convergence Layer will be 
defined in the H/2 Network Management Technical Specification. These MIB parameters may be moved into this 
section in a future edition of the present document. 
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Annex A (normative): 

Numbering and Coding Conventions 

Information elements and PDUs are transferred between the Ethernet SSCS and the underlying protocol layers in units 
of octets, in ascending numerical octet order (i.e. octet 1, 2, .., n-1, n), see figure A.l. 

MSB 



8 



Bits 
5 4 



LSB 
1 Octets 



1 
2 

n-1 
n 



Figure A.1 : Format convention 

When a field is contained within a single octet, the highest bit number (i.e. the bit labelled 8) represents the high order or 
most significant bit (MSB). 

In a multi-octet field the order (i.e. the significance) of bit values within each octet decreases as the octet number 
increases. For example, a 16-bit field is coded in the following way, see figure A.2. 



Octets 

1 



MSB 
8 


7 


6 


5 


Bits 
4 


3 


2 


LS 
1 


2 15 (MSB) 


2 14 


p13 


2 12 


2 n 


2 10 


2 9 


2 8 


2 7 


2 6 


2 5 


2 4 


2 3 


2 2 


2 1 


2° (LSB) 



Figure A.2: Corresponding coding in an IE or PDU 
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Annex B (informative): 

Association procedure for Ethernet SSCS 

Figures B.l to B.4 highlight the sequence of RLC procedures at association time that is specific to the Ethernet SSCS. 



MSC Association Ethernet SSCS 



xz 



1(1) 



Link_Agreed_or_Encryption_active_or_Authenticated 



Info Transfer 



CL Broadcast Joi 



3 



Setup_Radio_Connection_mobile_originated 



User_plane_operation_started 



z± 



Figure B.1 : High-level association procedure for Ethernet SSCS 
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MSC Info Transfer 



MT_CI_ I I MT_ACF I I MT_RLC I 


| AP_RLC | | AP_ACF AP_CL 




|| || 






/ Link_Agreed_or_Encryption_active_ 


orAuthenticated \ 




DLCJh 


FO_TRANSFER.req 


ACF_info_req 


RLCJNFO 


ACFJnfoJnd 


DLC_INFO_TRANd 






FO_TRANSFER.cnf 






ACF_info_cnf 






RLCJNFO_ACK 








ACF_info_rsp 


FER.ind 




DLCJNFO_TRANSF ER.rsp 




















DLC_II\ 













MT_Associated_to_AP 



Figure B.2: Info transfer procedure 
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MSCCL Broadcast Join 



I MT_CL l MT_ACF I MT_RLC I I AP_RLC I I AP_ACF I I AP_CL I 


II II 


/ MT_Associated_to_AP \ 


LC_CL_ 


BROADCAST_JOIN 


'eq 
ACFcl^roadcas 


joinreq 

RLC_CL_BROADCAST_JO 


N 
ACF_cl_broadCc 


stjoinjnd 

;l_broadcast_jc 






ACF_cl_t 

_BROADCAST_JOIN 






RLC 
roadcastjoincnf 






_CL_BROADCAST_JOIN_ACK 






DLCJ 

DLC_ 
ACF_cl_broadc 


IN.ind 




:L_BROADCAST__JC HN.rsp 




istjoinrsp 
















LC_CL 


cnf 










/ Broadcast_Join_Completed \ 
















I II ! I I I II II I 



Figure B.3: CL Broadcast Join procedure 
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MSC Setup_Radio_Connection_mobile_originated 



MT_CL 



MT_DUC I I MT_RLC 



AP_RLC I I AP_DUC 



AP_CL 



Broadcast_Join Completed 



DLC_SETUP.req 



DLC_CONNECT.ind 



DLC_CONNECT.rsp 



DUC_setup_req 



DUC connect ind 



DUC_connect_rsp 



RLC_SETUP 



RLC CONNECT 



RLC CONNECT ACK 



DUC_setup_ind 



DUC_connect_req 



DUC connect cnf 



DLC SETUP.ind 



DLC_CONNECT.re<| 



DLC_CONNECT.cnf 



Figure B.4: MT originated DUC setup procedure 
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Annex C (informative): 
Example of the MACJD table 



The MACJD table consists of mappings between Ethernet unicast, multicast and broadcast addresses to HIPERLAN/2 
MAC_IDs. In case of unicast and broadcast only one MACJD is used per Ethernet address. Ethernet multicast is 
mapped to HIPERLAN/2 unicast MAC_IDs and/or to HIPERLAN/2 multicast MAC_IDs (see table C. 1). 

Table C.1 : Example of the <MAC ID table> in the AP 



IEEE 802 MAC Address 
(48 bits) 


MAC IDs 


Broadcast address: 




(Ox) FF:FF:FF:FF:FF:FF 


223 


Multicast addresses: 




(0x)01:00:5E:00:00:00 


1,2,6 


(0x)01:00:5E:01:02:10 


225 


(0x)01:00:5E:12:B1:00 


3,2 


(0x)01:00:32:21:A1:01 


4,6 


MT addresses: 




(Ox) 00 


10:5A:2D:4D:83 


1 


(Ox) 00 


12:5A:3D:4D:82 


2 


(Ox) 00 


1 1 :4A:2C:33:43 


3 


(Ox) 00 


10:4E:2E:22:12 


4 


(Ox) 00 


11:2E:A1:11:A2 


5 


(Ox) 00 


12:3E:11:2A:1A 


6 
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